accesslog: support stat-level AccessLogFilter in stats AccessLog#42676
accesslog: support stat-level AccessLogFilter in stats AccessLog#42676TAOXUY wants to merge 4 commits intoenvoyproxy:mainfrom
Conversation
|
CC @envoyproxy/api-shepherds: Your approval is needed for changes made to |
ggreenway
left a comment
There was a problem hiding this comment.
To be consistent with other access loggers, using
to filter, and then having multiple instances of this access logger seems preferable. And that is already implemented.Is there a use case where that wouldn't be sufficient?
/wait-any
Updated the description. PTAL |
Signed-off-by: Xuyang Tao <taoxuy@google.com>
Signed-off-by: Xuyang Tao <taoxuy@google.com>
|
CC @envoyproxy/dependency-shepherds: Your approval is needed for changes made to |
89a8665 to
80af90e
Compare
|
Sry for making a push by mistake and loop in so many peoples. I am not maintainers and I cannot unassign the reviewers unfortunately. |
|
@wbpcode this feels weird to me from an API level because there's also a filter outside the access logger. But I can see how this would be useful in lowering the amount of config needed for some cases. WDYT? |
|
I don't have a strong opinion on adding this API - will let API folks decide. I think you are not saving much on the costs yet (you could have two access logs with two filters, instead of one access log filter each with filter), unless I'm missing something. Generally, you want to evaluate predicate as early as possible, so it's calling for some nested matcher support down the line. Access log filters are difficult to use IMO, harder than it should be. |
That's a good point actually. Though feasible, it seems not ideal. |
|
I believe this PR is waiting for API name change to be reversed. /wait |
Signed-off-by: Xuyang Tao <taoxuy@google.com>
updated. |
No commit has been pushed to the PR. (The waiting label will automatically be removed when a change is pushed.) Edit: even if github then shows the push as occurring in the past so that the sequence of events looks weird! |
|
I still think this is an awkward API with two different levels of the same filtering. @wbpcode can you weigh in as the api-shepherd on this PR? |
Hi @ggreenway , not only
Another use case as I put above is that we can use response_flag_filter(one of AccessLogFilter) to filter out connections with errors. |
|
Close for now, I will make another PR for filter tag value. |
Commit Message: with the PR, we can filter out stats based on their on AccessLogFilter within accesslogger. The use case can be like
Risk Level: no risk
Testing: added
Docs Changes: no need
Release Notes: no need as the stats AccessLog extension hasn't been released.
Platform Specific Features: no